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Abstract. The integration of Geographic Information Systems (GIS) 
and On-Line Analytical Processing (OLAP), denoted SOLAP, is aimed 
at exploring and analyzing spatial data. In real-world SOLAP applica- 
tions, spatial and non-spatial data are subject to changes. In this pa- 
per we present a temporal query language for SOLAP, called TPiet-QL, 
supporting so-called discrete changes (for example, in land use or cadas- 
tral applications there are situations where parcels are merged or split). 
TPiet-QL allows expressing integrated GIS-OLAP queries in an scenario 
where spatial objects change across time. 



1 Introduction 

In Geographic Information Systems (GIS), spatial data are organized in the- 
matic layers, stored in suitable data structures, while associated attributes are 
usually stored in conventional relational databases. In real-world applications, 
spatial objects in a layer can be added, removed, split, merged, or their shape 
may change. Tryfona and Jensen [T] classify spatio-temporal applications ac- 
cording with the kind of support of the changes occurring in the spatial objects. 
They distinguish between objects with continuous motion (e.g., a car moving 
in a highway), objects with discrete changes (e.g, parcels changing boundaries), 
and objects combining continuous motion and changing shapes (e.g., a stain in 
a river). On the other hand, OLAP (On-Line Analytical Processing) [5] provides 
a set of tools and algorithms that allow efficiently querying multidimensional 
repositories called Data Warehouses. OLAP data are organized as a set of di- 
mension hierarchies and fact tables, and can be perceived as a data cube, where 
each cell contains a measure or set of measures of interest. The problem of in- 
tegrating OLAP and GIS systems for decision-making analysis has been called 
SOLAP [3J. One of the models proposed for SOLAP is Pict jl], a framework 
that integrates spatial, spatio-temporal, and non-spatial multidimensional data. 
In this paper we add temporal capabilities to SOLAP, extending Pict-QL (the 
query language associated to the Piet data model) to support discrete changes. 

A Motivating Example. We present a typical scenario about land property in- 
formation. Figure [1] (left) shows four parcels of land, PI through P4, probably 
characterized by attributes like type of soil, owner. We assume that parcels are 
represented in a GIS layer denoted Li an d- Non-spatial information is stored in a 
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Fig. 1. Initial situation (left): land partition and Land dimension hierarchy; 
after merging P3 and P4 (right): changes in spatial objects and in the dimension 
hierarchy. 



conventional data warehouse. A dimension hierarchy denoted Land stores infor- 
mation related to the parcels. The bottom level of this dimension contains the 
parcel identifiers (pi through p4) . There is a mapping (not shown in the figure) 
between spatial objects in Li an( i and members of the bottom level (parcelld) 
of the dimension Land. At a certain moment, parcels P3 and P4 are merged 
into a single one P3-4. Changes must also be performed at the data warehouse, 
meaning that elements p3 and p4 are deleted and P3_4 is added, along with the 
corresponding rollups to region r2. A mapping between P3_4 and P3_4 is also 
defined. This is depicted on the right hand side of Figure [TJ Other changes may 
also occur. In a discrete changes scenario like this, we may want to know the 
history of P3-4, the production of each existing parcel as of the year 2006, or 
to pose queries like "Production by year per square mile for each parcel of land, 
for the parcels in Montevideo". Answering these kinds of queries requires ex- 
tending non-temporal SOLAP data models and query languages (like Pict-QL) 
with temporal capabilities. This is the problem we address in this paper where, 
after an overview of related work (Section [2]), we define the temporal data model 
(Section [3]). Then (Section |4| we present the syntax and semantics of TPict-QL, 
and discuss the expressiveness of the language. We conclude in Section [5] 



2 Related Work 



Rivest et al. [5] introduced the concept of SOLAP (standing for Spatial OLAP), a 
paradigm aimed at exploring spatial data by drilling on maps in a way analogous 
to what is performed in OLAP with tables and charts. Piet [3] is a formal 
model for SOLAP, where the integration between GIS and OLAP is materialized 
through a function that maps elements in the data warehouse to elements in 
the GIS layers. Piet comes equipped with a query language, Piet-QL [6], that 



supports the operators proposed by the Open Geospatial ConsortiurrQ for SQL, 
adding the necessary syntax to integrate OLAP operations through Piet- 
QL is designed to support (besides standard GIS and OLAP queries, GIS queries 
filtered using OLAP conditions, like "Name of the cities with total sales higher 
that 5000 units"; (d) OLAP queries filtered by spatial conditions, like "Total 
sales in cities within lOOKm from Montevideo" . Filtering is implemented through 
a predicate denoted IN. The Piet-QL query "Parcels crossed by the 'Uruguay' 
river, with sales greater than 5000 units" reads in Pict-QL. 

SELECT GIS Lid 
FROM land 1, rivers lr 

WHERE intersects(l,lr) AND lr.name = "Uruguay" AND 1 IN( 
SELECT CUBE filter([Land].[Land parcelld]. Members, 
[Measures]. [Parcel Sales] > 5000) 
FROM [Sales]); 

Here, 'land' and 'rivers' represent two thematic layers containing spatial ob- 
jects (the parcel subdivision of a given region, and the rivers, respectively). The 
OLAP subquery (identified with the keyword CUBE) is linked to the outer query 
by the predicate IN, and returns a collection of identifiers of spatial objects. 

The Spatio- Temporal Relational data Model (STRM), introduced by Tryfona 
and Hadzilacos [7], provides a set of constructs consisting in relations, layers, vir- 
tual layers, object classes, and constraints, all with spatial and temporal extent, 
on top of well-known models. In this model, a layer is a set of geometric figures 
like points, lines, regions or combinations of them, with associated values. The 
authors also define a layer algebra, which, based on four operations over layers, 
provides a semantics to SOLAP. 

Other proposals such as SECONDO [5] and Hermes [3] support moving 
object databases but, like other spatio-temporal models (except Piet), they are 
not oriented towards addressing the problem of integrating GIS, OLAP and 
Moving Object data. 

3 Spatio-Temporal Piet 

In the temporal extension to Piet (TPiet), each tuple in a relation is times- 
tamped with its validity interval. Time is introduced as a new sort (domain). 
For clarity of presentation, in the sequel we work with point-based temporal 
domains, although we use interval-based domains to implement our ideas [TU] . 
In temporal databases, the concepts of valid and transaction times refer to the 
instants when data are valid in the real world, and when data are recorded in the 
database, respectively [TTj. We assume valid time support. Also, a distinguished 
variable Now represents the (moving) current time instant. The lifespan of a GIS 
layer L, lifespan(L), is the collection of all the time instants where the layer is 
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valid. The lifespan of a set of layers C, lifespan(C), is the union of the lifespans 
of all the layers in C. Finally, we assume that no structural changes occur at the 
GIS or at the data warehouses, meaning that a layer containing polygons at its 
creation instant will contain polygons throughout its lifespan. 

Given the above, a Temporal GIS-OLAP Dimension Schema TG sc h is a tuple 
{H, A, T>, fj,), where H is a mapping from layers to geometries, A is a set of partial 
functions Att that map attributes in OLAP dimensions to GIS layers, T> is a set 
of dimension hierarchies [12] , and /j, a dimension level in a standard OLAP Time 
dimension. Elements in fi are in the temporal domain. Further, H, A, and T> 
satisfy the following conditions: (a) A layer is created when the first object 
is added to it; (b) H is constant throughout the lifespan of the GIS; (c) For 
each layer L, the function Att is defined only in lifespan(L); (d) The functions 
Att S A do not change with time, i.e., Atti(parcelld, Land) will always return 
Liand- (e) The schema of the dimensions in T> is constant during the lifespan of 
the GIS. Associated with a dimension schema, we have a dimension instance, 
which consists in: A set of relations r L . such that each tuple {gi, ext(gi), t)) in r L . , 
represents the existence of an object gi (and its extension) in Li at the instant 
t; A collection of functions a that map elements in OLAP dimension levels to 
geometric elements in a GIS layer, at a given time; A collection of dimension 
instances, one for each dimension schema D G T> in TG^. We assume that 
spatial objects have the same attributes throughout their lifespan. 

Temporal Piet Data Structure The data structure of TPiet-QL is organized in: 
(a) Application information. This is the data warehouse structure. Contains 
dimension and fact tables, (b) GIS information. The data structure for the map 
layers (one table per layer). Temporal attributes FROM and TO indicate the 
interval of validity of each object in a layer, (c) GIS-OLAP mapping information. 
Stores the relationship between geometric and application information (i.e., the 
a functions). Temporal attributes are also included here to indicate the temporal 
validity of a mapping, (d) There are also data structures to store precomputcd 
information containing the overlay of different layers (see [4]). 

We briefly explain the update semantics. When a new object is created at 
instant t\, say, in the layer Land, a tuple is inserted in the Land table with the 
corresponding parcel information. Attributes FROM and TO are set to t\ and 
the distinguished value Now, respectively. If this parcel, call it p\, is split into 
P2 and j»3 at instant t2, the tuple for pi is timestamped with TO=^2 — 1 (i-e., 
an instant immediately before £2 in the object's granularity); in addition, two 
tuples are created for P2 and p^, with FROM=t2, and TO=Now. Later, at £4, two 
parcels, p$ and pe are merged into a single one, call it p^e. The former two tuples 
are deleted as before (i.e., timestamped with TO=ti — 1), and p^e is created 
with FROM=i4 and TO=Now. The update operation at instant t is equivalent 
to the deletion of a tuple (i.e., a timestamping with t — 1), and the insertion, at 
instant t, of a new one (keeping the same identifier). The reincarnation operator 
is analogous to an update, except for the fact that the instants of deletion and 
insertion are not consecutive. 



We now discuss the data warehouse side. When operations on the GIS side 
require creating new spatial objects, the corresponding objects must be inserted 
in the warehouse dimensions, also defining new mappings. However, when an 
update occurs (like a change in an object's shape) the object identifier does not 
change and no action needs to be taken on the warehouse side. Also note that 
insertions can be performed without impacting the warehouse or the mapping 
function, although this could produce incomplete answers to some queries (the 
ones that involve accessing the warehouse), due to the incomplete mapping (i.e., 
the object would only be in one of the parts of the system) . One of the premises 
of the Piet data model is to allow autonomous maintenance of warehouse and 
GIS information. There are at least two possible situations: (a) The data ware- 
house and associated data cubes are non-temporal, in the sense that only fact 
tables are updated, and the dimensions are static, i.e., only the current state of 
the dimension data is available; (b) The data warehouse has temporal capabil- 
ities, i.e., dimensions are updated and their history is preserved. For example, 
the notion of slowly changing dimensions can be used [2], where a new dimen- 
sion tuple is added when an update occurs (dimension tables are extended with 
FROM/TO attributes). Other solutions can be found in the literature |13ll4j . 



4 Query language 

Definition 1 (Spatio-temporal object). We denote by spatio-temporal ob- 
ject a tuple of the form (objectld, geometry, attribute} , attribute n , interval), 
where geometry is the geometric extension of the object, attributei are alphanu- 
meric attributes, and 'interval ' is the interval of validity of the object, of the 
form [FROM, TO] . □ 

In Definition [1] interval is a single interval. In temporal databases it is usual 
to talk about temporal elements, i.e., sets of intervals. For simplicity of presen- 
tation, in this paper we work with single intervals instead of temporal elements. 
This makes the paper easier to read, without reducing its substance. In what 
follows we refer to spatio-temporal objects as 'objects', and denote Q a collec- 
tion of spatio-temporal objects. Based on Allen's interval set of predicates [15], 
in Figure [2] we specify the syntax and semantics of a collection of predicates over 
spatio-temporal objects, intervals, and time instants. 

Note that DURING and COVERS represent the predicate X DURING Y in Allen's 
algebra. OVERLAPS represents X OVERLAPS Y and Y OVERLAPS X. The same for 
MEETS, STARTS, and FINISHES. BEFORE and AFTER represent X < Y and Y < 
X, respectively. We also need some functions, namely: 

IIntersection(7i, 7 2 ) : TxTxTxT^TxT; returns the interval when 
I\ and I2 intersect. 

Coalesce^) : Analogously to the 'Coalesce' operator used in temporal databases, 
it produces groups of objects whose temporal intervals are consecutive and that 
coincide in all other attributes, returning a collection of spatio-temporal objects. 



StartsBefore(g,t) : Q x T — > boolean; 
Given a spatio-temporal object and an in- 
stant, returns True if t > g.FROM. 
BeginsAfter (g,t) : Q x T — > boolean; 
Given a spatio-temporal object and an in- 
stant, returns True if t < g.FROM. 
BEFORE (g, (ti, t 2 )) : Q x T x T -> boolean; 
Given a spatio-temporal object and an in- 
terval, returns True if g.TO < ti. 
DURING (g, (ti,t 2 )): Q x T x T -» boolean; 
Given a spatio-temporal object 
and an interval, returns True if 
t\ < g.FROM AND ti > g.TO. 

C0VERS(.g, (ti,t 2 »: Q x T x T ->• boolean; 
Given a spatio-temporal object and 
an interval, returns True if ti > 
g.FROM AND f 2 < g.TO. 



FinishesAf ter (g,t) : £/ x T — >• boolean; 
Given a spatio-temporal object and an in- 
stant, returns True if t < g.TO. 
AT(g,t) : Q x T — v boolean; Given a spatio- 
temporal object and an instant, returns 
True if t\ < g.FROM AND ti >= g.TO. 
AFTER(p, <ti,t 2 )): Q x T x T ->• boolean; 
Given a spatio-temporal object and an in- 
terval, returns True if ta < g.FROM. 
OVERLAPS^, (ti,t 2 )): Q X T X T -> 
boolean; Given a spatio-temporal ob- 
ject and an interval, returns True if 
(tl < g.FROM AND t a > g.FROM AND 
t 2 < g-TQ) OR (ti > g.FROM AND t 2 > 
g.TO AND ti < g.TO). 
MEETS(p, (ti,t 2 »: Q x T x T -»• boolean; 
Given a spatio-temporal object 
and an interval, returns True if 
tl = g.TO OR t 2 = g.FROM. 



Fig. 2. Predicates over spatio-temporal objects, intervals, and instants. 



Spatio-temporal Joins A key operation in any spatio-temporal query language is 
the join. Different kinds of temporal joins have been proposed in the literature 
[TTj . and two main classes can be identified: (a) Disjoint join; and (b) Over- 
lap join. In the former, given n (timcstamped) tuples, it is not required that 
their time intervals overlap. In the latter, the time intervals must overlap and 
there are two possibilities: all the time intervals have at least one common time 
instant, or they are joined in a 'chained' fashion, e.g., t\.TO > t2-FROM A 
t2.rO > t\.TO. Disjoint joins provide more expressiveness to a query lan- 
guage than overlap joins, allowing to query for asynchronous events (e.g., parcels 
owned by X before a region changed name). Examples (following Allen [15]) are 
bef ore-join(X,Y), and meet-join(X,Y) , with conditions X.TO < Y.FROM 
and X.TO = Y.FROM, respectively The joins above are denoted T-joins. When 
a T-join requires the equality of a collection of non-temporal attributes speci- 
fied as a predicate P a , we say that we are in presence of a GT-join (stand- 
ing for generic temporal). That is, a GT-join corresponds to the expression 
°~p a Aoveriap-join(x,Y) {X , Y). That means, given two tuples, the tuples in the re- 
sult of a GT-join will be the ones that have overlapping time intervals and verify 
the non-temporal predicate P a . In a spatio-temporal setting we can implement 
the temporal joins using the operators defined above. 

In the presence of spatio-temporal objects, the GT-join can be defined using 
the standard topological relationships |16| . like Touches(gi, 52), or Contains^, (72)- 
Consider two layers storing the histories of airports and cities. Figure [3] (left) 
shows two stages of city c\ \ one in the interval [0,50], and the other in the inter- 
val [51, Now]. Airport a\ was first relocated at instant 100, and then, due to the 
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Fig. 3. A city an its airport (left); Interaction of a\ and C\ along their timelines 
(right) 



city expansion, it was located well outside the new city limits. Figure |3] (right ) 
shows how the two objects a\ and c± interact along their timelines: the airport is 
within the city limits only in the intervals [51,100] and [101,200]. The relational 
representations are given below. 
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We can list the pairs city-airport such that an airport was within the city 
limits as a GT-join, where the non-temporal predicate Contains is spatial: 

a ^Airports x Cities) 

4> = contains ( Airport s.geom, Cities. geom) A overlap— j oin(Airports , Cities) 

The result would contain the tuples (al, cl, 51, 100) and (al, cl, 101, 200), 
representing (see Figure[3]), that between instants 51 and 100, al remained within 
the city limits of cl. 



The TPiet-QL Query Language The discussion above set the basis for defining a 
temporal extension to the GIS part of Piet-QL, yclding the TPiet-QL language. 

SELECT GIS [SNAPSHOT] [CURRENT] list .of .attributes 
FROM [OVERLAP] Tl tl,...,Tn tn 
WHERE <P 



Tl through Tn represent thematic layers, tl through tn range over the spatial 
or spatiotemporal objects in these layers, and the a^'s represent attributes of these 



objects. The OVERLAP keyword in the FROM clause states that the overlap join 
semantics must be applied (see below) . The list of attributes in the SELECT clause 
defines the schema of the result: a subset of the union of the attributes of the 
spatiotemporal objects mentioned in the FROM clause. The SNAPSHOT keyword 
(analogous to the one in TSQL2 [IT]) is used to return a non-temporal relation, 
eliminating the interval/s associated with each tuple in the query result. CURRENT 
is the same as SNAPSHOT but selecting the current state of the relation before the 
projection is performed. That means, the query will return a collection of spatial 
objects corresponding to the spatiotemporal ones which contain the keyword 
'Now' in the attribute TO. 

The condition <P is composed of conjunctions and disjunctions of the function 
and predicates mentioned above, and can also include the Piet-QL predicate IN 
(and the corresponding OLAP sub-query), to provide compatibility with Piet- 
QL, and to support OLAP in a spatio-temporal SOLAP scenario. This is why 
we keep the Piet-QL keyword GIS in the SELECT clause. We show this below by 
means of some examples. 

The semantics of the query is defined by the cartesian product of the geomet- 
ric objects in all the thematic layers in the FROM clause. If the OVERLAP keyword is 
specified, only the tuples whose intervals overlap are considered, (ie., the tuples 
such that C\u.intervai,i=i.n 7^ 0), and the overlapping interval is included in the 
result, which is coalesced by default using all the non-temporal attributes in the 
SELECT clause. We illustrate this semantics extending the city-airport example 
with a layer containing parcels, described in the table below (on the right we 
show the distances between cities and parcels, during different time intervals): 
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Consider a query asking for pairs city-parcel such that the distance between 
them is/was less than lOOKm. According to the usual semantics of a temporal 
join, the query returns tuples of the form (pi,Cj, Interval), where Interval is 
the interval when they where closer than lOOKm from each other. The query 
reads in TPict-QL: 

SELECT GIS c,p 

FROM OVERLAP Parcels p, Cities c 

WHERE Distance(c.the_geom,p.the_geom) < 100 

The result will be (note that this result is coalesced): 
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Let us give now an example of a TPiet-QL query returning an OLAP cube 
filtered with a spatio-temporal sub-query containing with SNAPSHOT clause: 
"Production cost and parcel sales in 2009, for the parcels crossed by rivers at 
that time" . This query reads: 

SELECT CUBE [Measures] . [Production Cost], [Measures] . [Parcel Sales], 
Product. [AlLProducts] ON ROWS 
FROM [Sales] 

WHERE AND [Time]. [2009] AND 
[Land]. [All Land] IN ( 

SELECT CIS SNAPSHOT Lid 

FROM OVERLAP Land 1, Rivers r 

WHERE Crosses(r,l) AND 

COVERS(r,[I/I/2009, 12/31/2009]) AND 

COVERS(1,[1/1/2009, 12/31/2009]) ) ; 

We conclude with the query: "Parcels crossed by the Uruguay river, with 
production sales greater than 5000 units". (Technically, in TPiet-QL, a GIS- 
OLAP query). 

SELECT CIS 1 

FROM OVERLAP land 1, rivers r 

WHERE Crosscs(l,r) AND r.namc = "Uruguay" AND Lid IN( 
SELECT CUBE 

filter( [Land] . [Land parcelld] .Members, 
[Measures]. [Parcel Sales] > 5000) 
FROM [Sales]); 

The query returns the spatiotcmporal objects containing the parcels with the 
requested production, their information, and the intervals when each parcel in 
the result crossed the Uruguay river. 

Expressive Power Over the data model described in Section [31 a formal spatio- 
temporal query language, denoted Ct, has been defined. This query language is 
studied in detail in [18]. We show now that TPiet-QL is based on this formal 
query language, and that most queries expressible in C t are captured by this 
temporal extension to Pict-QL. We illustrate these ideas using a very simple 
GIS-OLAP query, which includes a reference to an external data cube called 
'Production', with dimensions Land and Time, and measure 'quantity', repre- 
senting the production of wheat per year. The query asks for the parcels having 
an area larger than 100 Ha in 1996, currently larger than they were at that time, 
and with a production of wheat larger than 1000 Tons in 2009. The formal query 
in C t reads: 

Q = {p | (3e p ){ 3e pi )(3a)(3qty) 



area{e Pl ) = a A a > 100 A area{e p ) > a) A 

Production(p, 2009, qty) A qty > 1000}. 

Here, Production(p, 2009, qty) is a term representing a fact table, area is a 
function computing the area of a spatial object, and r l L (jp,e p ,t) are terms 
representing the parcels and their geometric extensions across time (in a point- 
based fashion) , corresponding to the elements in the model of Section [3] This 
query can be expressed in TPiet-QL as follows: 

SELECT CIS pi. id 

FROM land p, land pi 

WHERE area(p) > area(pl) AND 

COVERS(p,[1996,1996]) AND COVERS(pl, [2010,2010]) AND 
pl.id=p.id AND pl.id IN( 
SELECT CUBE 

filter ( [Land] . [Land parcelld] .Members, 
[Measures]. [qty] > 1000) 

FROM [Production]) SLICE [Time]. [2009]; 

The constructs Ct are present in the TPiet-QL expression above. The main 
difference is that instead of using non-temporal functions over the extensions of 
spatial objects like in C t , i.e., while area is applied over a geometry (e.g., e p ), 
TPiet-QL uses temporal functions over spatio-temporal objects (e.g., p). It can 
be seen that queries expressible in Ct can be expressed in TPiet-QL since there 
is a translation for each of the terms in one language to the other. We omit a 
term-by term proof for the sake of space. 

Vaisman and Zimanyi |19j recently proposed a comprehensive and formal 
classification for spatio-temporal data warehousing, defining a taxonomy of queries 
For example, the SOLAP class of queries is defined as the class containing the 
queries that can be expressed in relational calculus with aggregate functions, 
extended with spatial data types. Analogously, the ST-OLAP class of queries is 
the class containing the queries that can be expressed in the calculus extended 
with spatial and the moving types defined in |20j . We can say that our proposal 
falls somewhere in between the ST-OLAP and ST-TOLAP classes (the latter 
includes temporal OLAP support). 

5 Conclusion and Future Work 

We have presented a spatio-temporal query language for temporal SOLAP, de- 
noted TPiet-QL, that supports discrete changes in the spatial objects in the 
thematic layers of a CIS. TPict-QLextends Piet-QL, a query language for SO- 
LAP. We introduced the syntax an semantics of the language, and discussed its 
expressive power. Our next step is to produce an implementation, which includes 
a visualization tool for spatio-temporal data, and the development of efficient 
methods for query processing. 
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